home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 551 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.5 KB  |  73 lines
  1. Newsgroups: comp.std.c
  2. Path: howland.reston.ans.net!torn!sq!msb
  3. From: msb@sq.com (Mark Brader)
  4. Subject: Re: alignment requirements for all structures?
  5. Message-ID: <1996Mar12.175916.7256@sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1996Mar7.151216.1793@ittpub>
  8. Date: Tue, 12 Mar 1996 17:59:16 GMT
  9.  
  10. Wil Evers (wil@ittpub.nl) writes:
  11. > (1). Is there a rule in the C standard stating that the address of *every*  
  12. > structure - irrespective of its contents - should satisfy some alignment  
  13. > requirement? ...
  14.  
  15. No, there is no such rule.  The example code invokes undefined behavior.
  16. Each type has an alignment requirement, but each structure type is a
  17. different type with no necessary relation to any other structure type.
  18.  
  19. > (2). If the answer to (1) is no, then is a conforming compiler allowed to  
  20. > assign some specific alignment requirement to a data type, just because it  
  21. > is defined as a structure, and again irrespective of the contents of the  
  22. > structure?
  23.  
  24. Yes, it can.  Each structure type is a different type with no necessary
  25. relation to any other NON-structure type either.
  26.  
  27. > (3). If the answer to (2) is yes, why would a compiler want to do this?
  28.  
  29. On a word-addressed machine, the natural type of pointer -- the one which
  30. occupies one word and probably is the same size as an int -- points to a
  31. whole word.  A pointer to an individual byte requires additional storage,
  32. another word or halfword, to identify which byte in the word being pointed
  33. at is meant; and one or more additional operations are also necessary when
  34. dereferencing it, so access via the pointer is slower.
  35.  
  36. By aligning all structs on word boundaries, the implementation can use
  37. word-pointers rather than byte-pointers whenever pointers to structs are
  38. required.
  39.  
  40. > For example, if I write:
  41. >     #include <stdio.h>
  42. >     struct c { char data; } carray[10];
  43. >     int main() { printf("%u\n", sizeof carray); return 0; }
  44.  
  45. ... then on a word-addressed machine the output might very well be "40".  On
  46. that machine, sizeof (struct c *) would probably be 4 while sizeof (char *)
  47. would be 8, or maybe 6.
  48.  
  49. Also, some machines are byte-addressed but provide faster access to objects
  50. on word boundaries.  Implementers might choose to place everything that they
  51. could on word boundaries whether it was strictly necessary or not.  After
  52. all, *you* can always go and buy more memory, right?
  53.  
  54. It also seems conceivable that an implementer might want to align all
  55. structures *smaller than the machine's register size* on a word boundary
  56. so that struct assignment operations could be implemented efficiently
  57. by loading into, and storing from, a register.  I have had personal
  58. experience with a compiler where this was *not* done and the code
  59. I was maintaining, which assigned these little structs a lot, suffered
  60. a measurable speed penalty.  (We ended up replacing the original struct
  61. type, on implementations where there was an integral type of the same
  62. size, with a union of the two, using the integral type for assignments
  63. and the struct for member access.  [Yes, this is not strictly conforming.
  64. I think it should be; it's safe enough in practice.])
  65. -- 
  66. Mark Brader   | "On a word boundary, Luke, don't just hack at it. ...
  67. msb@sq.com    |  The bytesaber is the ceremonial weapon of the Red-Eye Knight.
  68. SoftQuad Inc. |  It is used to trim offensive lines of code.  Handwaving won't
  69. Toronto       |  get you anywhere.  Attune yourself with the Source."
  70.               |                 -- Steve Tarr, Alan Hastings, and Eric Raymond
  71.  
  72. My text in this article is in the public domain.
  73.